Virtual private network

ABSTRACT

The invention provides apparatus and methods for a Virtual Private Network (VPN) in a network that offers a simple user interface for efficient utilization of network resources. The VPN is defined for a specified set of endpoints each of which is associated with a single “hose.” A hose provides access to the VPN through an access point which may be a node of the network, for example. The hose is a single interface to the VPN for communication to all other endpoints of the VPN. The VPN achieves network resource allocation efficiency by exploiting resource sharing possibilities via multiplexing routing paths between endpoints and dynamic resource allocation techniques that permit real time resource allocation resizing. When a VPN is established with a VPN service provider, the routing paths between the endpoints of the VPN is optimized for multiplexing opportunities so that resource allocations between nodes along routing paths within the IP network is reduced to a minimum.

This non-provisional application claims the benefit of U.S. ProvisionalApplication No. 60/113,497, entitled “PERFORMANCE ORIENTED SERVICEINTERFACE FOR VIRTUAL PRIVATE NETWORKS” filed on Dec. 22, 1998 and U.S.Provisional Application No. 60/104,756, entitled “VIRTUAL PRIVATENETWORK” filed on Oct. 19, 1998. The Applicants of the provisionalapplications are Nicholas G. Duffield, Pawan Goyal, Albert GorderGreenberg, Partho Pratim Mishra, Kadangode K. Ramakrishnan, and JacobusE. van der Merwe. The above provisional applications and “A FLEXIBLEMODEL FOR RESOURCE MANAGEMENT IN VIRTUAL PRIVATE NETWORKS” by Duffield,Goyal, Greenberg, Mishra, Ramnakrishnan and van der Merwe are herebyincorporated by reference including all references cited therein.

BACKGROUND OF THE INVENTION

1. Field of Invention

The present invention relates to methods and apparatus for virtualprivate networks.

2. Description of Related Art

A private line network provides communications with guaranteedperformance because entities that are connected to the private linenetwork are limited to only those parties that communicate with oneanother. In addition, the private line network provides a level ofinherent security because parties other than the communicating partiescannot gain access to the network.

The above advantages are counter balanced by inflexibility (e.g., addingnew endpoints requires new network upgrades), and network resources aredetermined by peak traffic conditions. Moreover, interfacing to privateline networks is complex because detailed knowledge about the network isrequired, including particularities regarding endpoints and connectivityto the endpoints. Thus, there is a need for new technology to provideprivate line network service without the above mentioned drawbacks.

SUMMARY OF THE INVENTION

The invention provides apparatus and methods for a Virtual PrivateNetwork (VPN) in a network such as an Internet Protocol (IP) Networkthat offers a simple user interface for efficient utilization of networkresources. The VPN is defined for a specified set of endpoints, each ofwhich is associated with a single “hose.” A hose provides access to theVPN through an access point which may be a node of the network such as aserver, a router or an Internet Service Provider (ISP), for example. Thehose is a single interface for a user or “customer” to the VPN forcommunication to all other endpoints of the VPN.

Customers of the VPN are relieved of the burden to obtain detailedknowledge of the VPN. To interface with the VPN, each customer is onlyrequired to specify a hose profile of the hose associated with thecustomer's endpoint. The hose profile may be an aggregate communicationspecification such as bandwidth or other quality of service requirementsor more detailed description of the desired communication trafficcharacteristics. The VPN guarantees communication performance up to thehose profile for each of the endpoints.

The VPN achieves network resource allocation efficiency by exploitingresource sharing possibilities via multiplexing routing paths betweenendpoints and dynamic resource allocation techniques that permit realtime resource allocation resizing. When a VPN is established with a VPNservice provider, the routing paths between the endpoints of the VPN isoptimized for multiplexing opportunities so that resource allocationsbetween nodes along routing paths within the IP network is reduced to aminimum. In addition, while initial resource allocations may be dictatedby worst case requirements of the hose profiles associated with theendpoints, real time measurement of actual VPN traffic allows adaptiveresizing of network resource allocations so that initially allocatednetwork resources may be applied to other uses that would otherwise bewasted. Thus, network resource allocations for the VPN achievessignificant gains over private line networks.

The VPN service provider may achieve further allocation efficiency byexploiting multiplexing possibilities across multiple VPNs and resourcesharing possibilities with other non-VPN communication traffic. In thisway, VPN customers not only are relieved of the need for detailednetwork expertise, but also gain significant cost savings due to networkresource utilization efficiencies not possible with private linknetworks.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention is described in detail with reference to the followingfigures wherein like numbers designate like elements, and wherein:

FIG. 1 is an exemplary block diagram of a VPN emulating a private linenetwork;

FIG. 2 is an exemplary block diagram of a hose VPN;

FIG. 3 is an exemplary diagram of a customer managed hose VPN;

FIG. 4 is an exemplary diagram of a VPN service provider managed hoseVPN;

FIG. 5 is an example of a set of network nodes connecting endpoints of aVPN;

FIG. 6 is a flow chart of an exemplary process for allocating andinitializing a hose VPN;

FIG. 7 is an exemplary block diagram of an access point;

FIG. 8 is a flow chart of an exemplary access point process for handlingdata packets from a hose; and

FIG. 9 is a flow chart of an exemplary process for resizing allocatednetwork resources of a hose VPN.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

FIG. 1 shows an example of a VPN 150 operating in a network system 100that provides a private line network service in a network 150. Customernetworks 110-140 are VPN endpoints that communicate with one another viathe network 150. In the network system 100, each customer network110-140 must allocate a set of customer communication links 151-156between pairs of source-destination endpoints and specify communicationlink parameters such as bandwidth, packet delay, etc.

In the above VPN, the customer networks 110-140 bear the burden fornetwork resource allocation and, thus, operators of the customernetworks 110-140 must have precise knowledge of the amount of trafficflowing among the endpoints to the VPN to set desired bandwidth andquality of service (QOS). Once allocated, network resources such asbandwidth of nodes within the network 150 that are assigned for eachcommunication link 151-156 cannot be used for other communications evenwhen not in use for the intended VPN. Thus, inefficiencies in networkresource utilization results which reduces an ability of the network 150to support a volume of communication that might otherwise be supported.

FIG. 2 is an exemplary diagram of a hose VPN system 200 that includeshoses 210-216 to a VPN and a network 250. The network may be of any kindsuch as a switched network, an asynchronous transfer network (ATM), orother data or analog networks. For the following discussion, theInternet Protocol (IP) network is used as an example.

The IP network 250 includes a plurality of access points 218-224 whereeach of the access points 218-224 is associated with one of the hoses210-16. The hose VPN system 200 provides VPN services to customernetworks 202-208 and each of the customer networks 202-208 gains accessto the VPN via one of the hoses 210-216, for example.

The customer networks 202-208 may be any customer proprietary networksuch as a local area network (LAN) (e.g., an Internet Service Provider(ISP)), wide area network (WAN), or the like. While FIG. 2 showscustomer networks 202-208, any communication device capable ofestablishing a communication connection with the access points 218-224may be used in place of or in conjunction with the customer networks202-208 without departing from the spirit and scope of the invention.

The customer networks 202-208 access the VPN (i.e., utilize VPN service)through a respective access point 218-224. The access points 218-224 arecoupled to each other via communication links within the IP network. Theaccess points 218-224 may be any type of device or system that providesaccess to the IP network 250. For example, the access points 218-224 maybe Internet Service Providers (ISPs), network servers, routers, or thelike.

A hose 210-216 provides access to a VPN that is supported by the IPnetwork 250. When associated with the same VPN, the hoses 210-216 areendpoints of the VPN. Thus, each of the customer networks 202-208communicates via one hose 210-216 to any of the other endpoints (i.e.,other customer networks 202-208 that are also part of the same VPN).Each hose 210-216 is specified by a service level agreements (SLA)without reference to other endpoints. Once agreed, the VPN guaranteesperformance of the hose 210-216 independent of a type or destination ofcommunication traffic of the hose 210-216 as long as the communicationtraffic remain within the SLA. Thus, a customer network 202-208 (or anoperator of the customer network 202-208) need not specify performancefor each of the endpoints that may be a destination. Rather, thecustomer network 202-208 only provide the SLA for its hose 210-216 andthe VPN performs the functions required to meed the SLA.

Accordingly, once SLAs for all hoses 210-216 of a VPN are completed, theVPN is specified and the IP network 250 guarantees the performance suchas connectivity and bandwidth required to meet the SLAs. In this way,operators of the customer networks may be relieved of tasks associatedwith routing, network management, network performance, etc. In addition,the IP network 250 may be optimized to utilize resource sharing bymultiplexing communication paths within each VPN and across multipleVPNs as well as take advantage of available resources supporting non-VPNcommunications.

SLAs for each of the hoses 210-216 may be based on one or more QOSrequirements. For example, the hose 210 may have an SLA that requiresthree QOS levels of. QOS A, QOS B and QOS C. In addition, a timeschedule may be associated with each of the QOS levels so that the levelof support may be varied with time. For example, QOS A may require 10megabits per second (mb/s) constant bit rate to support real time videocommunication, QOS B may require support for 5 mb/s file transferprotocol (ftp) data transfers while QOS C may require 56 kilobits persecond (kb/s) for e-mail. Also, QOS A may be needed only during workinghours from 8 a.m. to 5 p.m., Monday through Friday, while QOS B may beneeded for afternoon and evening hours between 1 p.m. and 8 p.m. and QOSC may be always required. All of the above requirements are collectedtogether as a hose profile corresponding to each hose 210-216. The VPNservice provider guarantees that the hose profile is met for each of thehoses 210-216 of the VPN. The SLA for hoses 210-216 may be based ontraffic characteristics such as reasonable delay, packet loss rates,jitter, bandwidth minimums, and the like for various time periods. Forexample, an IP voice VPN service provider might require tight bounds onthe per-packet loss rates, delay and possibly the amount of jitter. Onthe other hand, a data only VPN service provider might have relativelyless stringent delay requirements. Also, as mentioned earlier, theserequirements may be needed only for certain time intervals and may berelaxed during other time intervals.

The interface between the customer networks 202-208 and the associatedhoses 210-216 may be managed by either the customer or the VPN serviceprovider. If the VPN is established for a single QOS, then themanagement task is reduced to guaranteeing an effective bandwidth amongall the access points 218-224 of the VPN. While QOS may be specified interms of bandwidth, end-to-end delay, bit rate, error rate, etc., all ofthese qualities may be reduced to an effective bandwidth which the VPNservice provider guarantees for each of the hoses 210-216.

For example, if a VPN is established between customer networks 202 and208 and the associated hoses 210 and 216 are specified to require a 10mb/s for each direction, the VPN service provider may satisfy the aboveVPN requirements by allocating 10 mb/s bandwidth in the access points218 and 224 as well as 10 mb/s duplex connections between the accesspoints 218 and 224. Assuming that a shortest path between the accesspoints 218 and 224 traverses three nodes of the IP network, the VPNservice provider must allocate 10 mb/s of bandwidth in each of thesenodes for both directions.

While the above simple VPN may appear to be supported by forming a pipebetween the access points 218 and 224 without any multiplexingopportunities, the VPN service provider may take advantage of resourcesharing between the resources allocated for the VPN and resourcesdevoted for other non-VPN communications. For example, while 10 mb/s maybe initially allocated for each direction to support a VPN, the networkresource allocations may be resized based on actual VPN trafficexperienced between the access points 218 and 224. In this way, the IPnetwork resources may be adaptively allocated so that un-utilizedresources may be devoted for other IP network communications.

The VPN management task becomes much more difficult when multiple QOSlevels are desired. For these more complex management situations, themanagement of the customer network interface may be divided into fourcases as shown in Table 1 below. Cases land 2 correspond to customermanaged hoses 210-216 and cases 3 and 4 correspond to VPN serviceprovider managed hoses 210-216.

In case 1, the customer may manage the outgoing hose traffic bycontrolling the rate of data packets output through the hoses 210-216from different applications based on a priority scheme. Thus, higherpriority applications may output more data packets than lower priorityapplications. After the data packets enter the hoses 210-216, the datapackets are not distinguished from each other but are only identified bya VPN identification (ID), for example. Thus, for case 1, the VPNservice provider does not distinguish one data packet from anotherwithin a single VPN, but only distinguishes one VPN from another. Thus,for case 1, the VPN service provider may only take advantage ofpotential multiplexing opportunities based on a single effectivebandwidth hose profile. Other techniques may also be used such asweighted fair queuing so that different applications within the customernetwork may be assigned different weights and data packets from eachapplication are allocated bandwidths through the hoses 210-216 based onthe associated weights.

TABLE 1 Customer Network Interface VPN Service Provider Managed One VPNCustomer, Managed for each QOS Hose Input Case 1 Case 3 SchedulingCustomer controls the Customer assigns applications volume of packetsfrom to appropriate VPNs. The applications based on VPN service providerpriority or weighted fair schedules customer queuing techniques, forcommunication traffic based example. on the QOS and VPN. Packet Case 2Case 4 Marking Customer marks data Customer and VPN service packets.Network processes provider mark packets. marked data packets up toCustomer markings are the hose profile. honored as long as hose profileis met. Can optimize across VPNs having same QOS within the network.

In case 2, the customer manages the communication traffic through thehoses 210-216 by marking individual data packets. For example, each datapacket is marked corresponding to the QOS assigned to the correspondingapplication. All the marked data packets are output to the hoses 210-216and the VPN service provider processes the data packets based on themark of each data packet. The VPN service provider will process all themarked data packets up to the hose profile. Data packets output throughthe hoses 210-216 that exceed the hose profile, may be dropped orhandled in a best effort manner which may be specified in the hoseprofile.

FIG. 3 shows a diagram illustrating a VPN having customer managed hoses.Each of the customer networks 202-208 may independently define the hoseprofile for its respective hose 210-216. For example, the customernetwork 202 has a hose profile that has requirements for QOS A, QOS Band QOS C data packets while the hose profile for the hose 216 specifiesrequirements for QOS A and QOS B data packets. Similarly, a hose profilefor the hose 212 specifies requirements for QOS A and QOS C data packetswhile a hose profile for the hose 214 specifies requirements for QOS Band QOS C data packets. If the customers use hose input scheduling, thedesired communication performance is managed by the customer networks202-208 allocating the hose bandwidth to its applications. The VPNguarantees the aggregate effective bandwidth specified in each of thehose profiles. If data packet marking is used as in case 2, the datapackets are marked as QOS A, QOS B or QOS C and the VPN service providerhandles the data packets according to the effective bandwidth specifiedin the hose profiles.

In case 3, the VPN service provider manages the hoses by defining aseparate VPN for each QOS level. The customer networks 202-208 merelyassign the appropriate VPN to applications that require the QOS levelguaranteed by that VPN. Thus, the customer networks 202-208 do notperform any scheduling but rather output data packets of different QOSlevels to respective VPNs.

In case 4, the VPN service provider establishes various VPNscorresponding to the QOS levels required and the customer networks202-208 mark each of the data packets corresponding to the QOS level. Inthis case, the VPN service provider honors the markings of the datapackets until the hose profile is reached. For example, if the customernetwork 202 marks a data packet to be QOS A, the VPN service providertransmits the data packet in the QOS A VPN until the QOS A hose profileis reached. QOS A marked data packets that exceed the hose profile maybe given lower priority or best effort performance depending on networkconditions. In some situations, the hose profile may specify bursttraffic conditions where for a prespecified amount of time, thebandwidth may exceed a base level by some predetermined amount. In thissituation, QOS level markings of data packets are ignored only when theburst condition parameters of the hose profile are exceeded. Thus, theVPN service provider is policing the flow to ensure that marking applyonly to communication traffic within the hose profile.

FIG. 4 shows a VPN that corresponds to the VPN shown in FIG. 3 with theexception that the VPN shown in FIG. 4 is a service provider managedVPN. Because the customer network 202 requires three QOS levels, thehose 210 includes three sub-hoses, one sub-hose corresponding to each ofthe QOS levels A, B and C. Similarly, the other hoses 212-216 mayinclude sub-hoses for the corresponding QOS levels specified by each ofthe respective customer networks 204-208.

The VPN shown in FIG. 3 provides benefits for the customer networks202-208 because the specification of the hose profile is simplified. Thesimplification is achieved because the customer networks 202-208 arerequired only to specify aggregate hose profiles instead of a specifichose profile for each QOS level. However, because only the aggregatehose profile is provided, the VPN service provider has less opportunityto take advantage of possible multiplexing than if more specific hoseprofile specifications were provided. Thus, the VPN service provider maybe forced to allocate (at least initially) the maximum requiredbandwidths to guarantee the hose profile required performances.

In contrast, in the VPN shown in FIG. 4, the customer provides the VPNservice provider bandwidth information required for each of the desiredQOS levels for each of the endpoints. Thus, multiplexing among endpointsof each VPN may be achieved as well as resource sharing may be exploitedacross the VPNs allocated to all the QOS levels to reduce IP networkresource allocations.

The VPN service provider may allocate network resources based on networkoptimization options as shown in Table 2 below. There are three possiblenetwork optimization strategies: 1) pipe; 2) source/sink tree; and 3)total VPN. As shown in Table 2, the degree of multiplexing ranges fromlow to high as discussed below.

TABLE 2 Network Optimization Options Network Strategy Degree ofMultiplexing Pipe Low Source/Sink Tree Medium Total VPN High

FIG. 5 shows an example of a virtual network having customer networks202, 206 and 208 connected to hoses 210, 214 and 216 as endpoints. Fordiscussion purposes, assume that nodes 302 labeled A-G are allocated forthe above VPN.

Table 3 below shows the pipe network optimization in terms of the nodesA-G. Assume that the hose profile corresponding to each of the hoses210-216 requires 1 mb/s for communication between the customer network202 to the customer network 208 and between the customer network 202 andthe customer network 206. If the shortest routing path between thecustomer networks 202 and 208 is via nodes A-C-B-E then the totalbandwidth allocation in the network may be represented by the sum of thebandwidths between each adjacent node. Thus, the bandwidth between nodesA and C is 1 mb/s; the bandwidth between nodes C and B is 1 mb/s; andthe bandwidth between nodes B and E is 1 mb/s. Thus, the networkresource allocation between the customer network 202 and customernetwork 208 is 3 mb/s.

TABLE 3 Pipe Network Optimization Shortest Total Endpoints BandwidthRouting Path Allocation Allocation A → E 1 mb/s A → C → B → E 3 mb/s 6mb/s A → G 1 mb/s A → C → D → G 3 mb/s

Similar to the above, the network resource allocation between thecustomer networks 202 and 206 is 3 mb/s for the routing path of A-C-D-G.Thus, the total network resource allocation to support the hose profilefor the hose 210 is 6 mb/s.

The above pipe network optimization basically allocates the maximumbandwidth required as if a pipe is constructed between nodes A and E andbetween nodes A and G. While initial bandwidth allocation may be 6 mb/s,the VPN service provider may monitor the actual VPN traffic and “resize”the network resource allocations based on the monitoring result. In thisway, the network resource allocation may be adjusted to track the actualbandwidth usage for the VPN and adaptively adjust the networkallocations accordingly.

In addition, the VPN service provider may share network resources withother non-VPN communication traffic so that when network resourcesallocated to the VPN are not used, the VPN service provider may utilizethe allocated network resources for other purposes. For example, theunused network resources may be used for best effort IP network trafficuntil those resources are required to guarantee VPN performance.

Table 4 below shows an example of a first source tree networkoptimization. A source tree is a tree of connecting paths that emanatefrom a source hose 210-216 to a destination hose 210-216. For example,the source tree for the hose 210 originates from node A and extends tonode C. If the shortest routing path is assumed, the source treebranches at node C to nodes B and D. The node B branch continues to nodeE while the node E branch continues to node G. This source tree obviatesthe fact that the branch A-C is common between the two branches C-B andC-D. Because the common branch A-C is only required to support thebandwidth allocated to the source, the hose 210, the bandwidthallocation for the branch A-C does not need to exceed the hose profileof the hose 210. Thus, as shown in Table 4, the network resourceallocation may be 3 mb/s for the source tree branches A-C-B-E and 2 mb/sfor the branches C-D-G. The total bandwidth allocation is 5 mb/s whichis 1 mb/s less than the pipe network optimization of Table 3. Thus, thebandwidth gain of the source tree network optimization over the pipenetwork optimization is 6/5 or 1.2.

TABLE 4 First Source Tree Network Optimization Shortest Total EndpointsBandwidth Routing Path Allocation Allocation A → E 1 mb/s A → C → B → E3 mb/s 5 mb/s A → G 1 mb/s → D → G 2 mb/s

Table 5 below shows a second source tree network optimization that takesadvantage of an explicit routing path instead of relying on the shortestrouting path. For example, instead of routing data packets throughbranches C-B-E and C-D-G, the data packets are routed through branchesC-F-E and C-F-G, the branch between nodes C and F become common for thetree source between the hose 210 to the hose 216 and the hose 210 to thehose 214. Since the branches A-C and C-F of the source tree are requiredto support only the hose profile for hose 210, the bandwidth allocationfor the branches A-C and C-F are 1 mb/s each. The remaining allocationsare for the branches F-E and F-G which are both limited to the hoseprofiles for the hoses 216 and 214, respectively, and are both 1 mb/s.Thus, the total bandwidth allocation for the second source tree networkoptimization is 4 mb/s. Accordingly, the gain of the second source treenetwork optimization over the pipe network optimization is 6/4 or 1.5.

TABLE 5 Second Source Tree Network Optimization Explicit Total EndpointsBandwidth Routing Path Allocation Allocation A → E 1 mb/s A → C → F → E3 mb/s 4 mb/s A → G 1 mb/s → G 1 mb/s

The above source tree network optimizations take advantage of theability to multiplex branches of the source tree for communicationtraffic destined to different endpoints. Thus, the branch A-C ismultiplexed between the communication traffic between the hose 210 tothe hose 216 and between the hose 210 and the hose 214. Similarly, thesecond source tree network optimization multiplexes both the A-C branchand the C-F branch between the hose 210 to the hose 216 and the hose 210to the hose 214 communication traffic.

Table 6 below shows a total VPN allocation for the second source treeoptimization where all possible VPN communication traffic is included.The first row of table 6 shows the communication traffic between thehose 210 and the hoses 214 and 216, the second row shows thecommunication between the hose 216 and the hoses 210 and 214 and thethird row shows the communication between the hose 214 and the hoses 210and 216. As before, if the explicit routing path of the above secondsource tree network optimization is used, the total network allocationis 4 mb/s for each of the above hoses 210-216 which results in a totalnetwork allocation of 12 mb/s.

TABLE 6 Total VPN Allocation for Second Source Tree OptimizationExplicit Total Endpoints Bandwidth Routing Path Allocation Allocation A→ E 1 mb/s A → C → F → E 3 mb/s 12 mb/s A → G 1 mb/s → G 1 mb/s E → A 1mb/s E → F → C → A 3 mb/s E → G 1 mb/s → G 1 mb/s G → A 1 mb/s G → F → C→ A 3 mb/s G → E 1 mb/s → E 1 mb/s

Table 7 below shows a VPN network optimization where furthermultiplexing may be exploited. If the network resource allocation isfirst performed for satisfying the hose profile for the hose 210 (row1), then path A-C-F-E is allocated for communication traffic between thehose 210 and the hose 216 and an additional allocation for path F-G isneeded for communication traffic between the hose 210 and the hose 214.This allocation is identical with the allocation for the second sourcetree network optimization which takes advantage of multiplexing alongpaths A-C and C-F. In row 2, the allocation for the communicationtraffic from the hose 216 to the hose 210 requires 1 mb/s for each ofthe paths E-F-C-A. The allocation for the communication traffic betweenthe hose 216 and the hose 214 requires the paths E-F and F-G. However,the path E-F may be multiplexed between the communication traffic of thehose 216 to the hose 210 and the hose 216 to the hose 214. Similarly,the path F-G may be multiplexed between the traffic from the hose 216 tothe hose.214 and the hose 210 to the hose 214 as shown in row 1. Thus,the allocation for the path between F to G that was allocated in thesecond source tree optimization is not necessary. Those not allocatedare shown in bold and italicized.

TABLE 7 VPN Network Optimization Explicit Total Endpoints BandwidthRouting Path Allocation Allocation A → E 1 mb/s A → C → F → E 3 mb/s 8mb/s A → G 1 mb/s → G 1 mb/s E → A 1 mb/s E → F → C → A 3 mb/s E → G 1mb/s → G G → A 1 mb/s G → F → C → A 1 mb/s G → E 1 mb/s → E

As shown in row 3, further multiplexing may be achieved for thecommunication traffic between the hose 214 and the hoses 210 and 216.Aside from the path G-F that is required to guarantee the hose profilecorresponding to the hose 214, the remaining paths may be multiplexedbetween the communication traffic from the hose 214 to the hose 210 andthe communication traffic from the hose 216 and the hose 210 as well asthe communication between the hose 210 and the hose 216. Thus, theadditional bandwidth allocation to support the hose profilecorresponding to the hose 214 is only 1 mb/s. Accordingly, the totalresource allocation for the VPN network optimization is 8 mb/s. Thus,the VPN network optimization has a gain of 3 over the pipe networkoptimization.

FIG. 6 shows a flow chart for an exemplary process to initially allocatenetwork resources for a hose VPN. In step 1000, a request is receivedfor VPN service and the process goes to step 1002. In step 1002, it isdetermined whether allocation of hose resources should be customermanaged or VPN service provider managed. If customer managed, theprocess goes to step 1004; otherwise, the process goes to step 1008. Instep 1004, the VPN service provider negotiates hose profiles with thecustomer (or with each of the customer networks 202-208). Suchnegotiations may be conducted automatically via currently available orfuture protocols or may be negotiated between the VPN service providerbusiness entity and the customer business entity. The negotiations mayconsider tradeoffs between QOS desired and costs incurred, for example.After the hose profiles are determined, the process goes to step 1005.In step 1005, the VPN service provider assigns a VPN identification (ID)to the requested VPN and goes to step 1006. In step 1006, the VPNservice provider determines optimal routing to guarantee the requiredservices as specified in the hose profiles and goes to step 1012.

In step 1008, the VPN service provider negotiates hose profiles for eachof the QOS classes desired and goes to step 1009. In step 1009, the VPNservice provider assigns VPN IDs for each of the QOS classes and goes tostep 1010. In step 1010, the VPN service provider determines the optimalrouting for each of the VPNs. For example, the VPN service provider mayconsider any multiplexing that may be achieved for each VPN and/oracross all the VPNs. After the optimal routing has been determined, theprocess goes to step 1012.

In step 1012, the process allocates the network resources based upon theoptimal routing determined in prior steps and goes to step 1014. In step1014, the process determines whether the customer has chosen to mark thedata packets that are transmitted. If packet marking is desired, theprocess goes to step 1016; otherwise, the process goes to step 1018. Instep 1016, the VPN service provider receives the packet marks chosen bythe customer (or the VPN service provider provides the packet marks tothe customer) and initializes the packet marks in the network nodes thatare selected based on the optimal routing paths and goes to step 1018.In step 1018, the VPN service provider initializes the allocated networkresources and commences the VPN process and goes to step 1020 and endsthe initial network resource allocation process.

The VPN service provider may monitor VPN traffic to predict trafficrates so that SLAs for hoses 210-216 may be adjusted or resized toactual usage patterns. The access points 218-224 and/or other networknodes may monitor the incoming traffic to hoses 210-216 to collect hosetraffic information as well as to ensure that the hose profiles are notviolated. Similarly, traffic at a hose egress (i.e., traffic that hastraversed the network) may be monitored for the same purposes.

Based on the information that is collected by the above monitoring, theVPN service provider may use network resource reservation mechanisms toresize current network resource allocations and provide prediction datafor resizing the hose profile. Initially, the network resourceallocations may be made statically by taking into account worst caseresource demands. The initial allocations may then be resizeddynamically based on monitoring measurements. The resizing of theallocation may be restrained by the hose profiles as specified in theSLAs such that the resizing cannot cause the hose capacity to fall belowa level required to provide the required QOS requirements. However, whenwithin the hose profiles, the resizing of the resource allocation allowsmore resources to be freed-up for use by other traffic and thus, moreefficient use of the resources is possible. In addition, the hoseprofiles themselves may also be renegotiated based on the usage datagenerated based on the data produced by the monitoring process. Themonitoring and resizing functions are discussed below in connection withan exemplary access point block diagram.

FIG. 7 is an exemplary block diagram of an access point 218, forexample. Although the access point 218 is described, it should beappreciated that the other access points 220-224 may have similararchitecture. In addition, with the exception of the hose interface 330,FIG. 7 may also represent a node in the IP network 250. The access point218 includes a controller 310, an IP network interface 320, a customernetwork interface 330, a resource usage measurement device 340, a memory350 and a prediction device 360. These elements are coupled together viaa signal bus 370. While a bus architecture is shown for ease ofillustration, other architectures are possible, as is well known to oneof ordinary skill.

When the customer network 202 requests a hose 210 for accessing a VPN,the access point 218 negotiates with the customer network 202 todetermine an SLA to specify a hose profile for the hose 210. Thesuccessfully negotiated SLA is stored in the memory 350. The hoseprofile may include information related to the amount of trafficexpected and the QOS(s) desired. The QOS may be a measure of data packetloss, delay, jitter and the like as discussed earlier. Other SLAparameters may be stored in the memory 350 and used to determineresizing of hose capacity as described hereafter.

Based on the hose profile, the access point 218 establishes the hose 210between the customer network 210 and the VPN. The access point 218 mayalso communicate with other nodes of the IP network 250 to establishrouting paths. As discussed earlier, various VPN network optimizationschemes may be used. Thus, the access point 218 may perform managementfunctions of the VPN service provider to establish and administer theVPN.

The traffic information transmitted over the hoses 210-216 may be datapackets. Each data packet may include header information identifying thesource, destination, data packet sequence number, QOS markings and thelike. Based on the header information of the data packet, the controller310 forwards the data packet via the IP network interface 320 to a nextnode or access points 220-224 in the IP network which may be determinedby a routing scheme selected by the VPN service provider, such asshortest path or explicit routing path.

The access point 218 may perform monitoring functions by measuringcurrent resource usage via the resource usage measurement device 340.For example, the resource usage measurement device 340 may measure theused bandwidth, packet loss, and/or other transmission parameters viadirect measurement of the data stream, a standard network messageprotocol (SNMP) or other signaling interfaces such as the SS7. Theresource usage measurements are then input to the prediction device 360and used to predict hose capacity needed for the hose 210. Based on thepredicted hose capacity, the controller 310 may renegotiate the capacityof the hose 210 to resize the hose 210 for greater network resourceallocation efficiency. Other network resource allocations may also bedynamically resized based on the predictions generated by the predictiondevice 360.

As an example of a hose capacity prediction technique, traffic flowmeasurements gathered at regularly spaced instants during a window ofduration T_(meas) may be considered. The measurements may be used topredict an effective bandwidth for the traffic flow over some window ofduration T_(ren) following the measurement window.

The predicted effective bandwidth may be set to the maximum bandwidthmeasured during the measurement window T_(meas) Alternatively, thepredicted effective bandwidth may be set equal to m+α√{square root over(v)}, where m and v are respectively the mean and variance of thebandwidths sampled during the measurement window and αis a multiplierthat controls the extent to which the negotiated bandwidth accommodatesvariability in the samples. The interpretation of a is that in aGaussian approximation to the bandwidth distribution. The bandwidthm+α√{square root over (v)} is expected to be exceeded with probabilityl-G(α), where G is the cumulative distribution of the standard normaldistribution.

If the interval between hose capacity renegotiations encompasses periodsof systematic variation, the above predictions may become inaccurate. Inorder to remedy these inaccuracies, two approaches may be followed.First, a worst case predictor over the largest time scale of variation,e.g., the maximum bandwidth over a day for telephone traffic, may beused to compensate for inaccuracies. Second, historical data may be usedto predict trends. For example, when average telephone call arrivalrates are a known constant process Q(t), then instead of using apredicted bandwidth S(t) directly, the predictor S(t)Q(t+T_(ren))/Q(t)may be used. Here, the ratio Q(t+T_(ren))/Q(t) is used to model thesystematic change of the arrival rate upwards or downwards.

In addition to the inaccuracies created by systematic variations, thereare two statistical effects which, if uncorrected, may cause theprediction to underestimate bandwidth requirements. The first issampling error and the second is short-time scale burstiness. Estimationof mean and variance is subject to inherent sampling error since theestimates are themselves random variable. This additional variabilitycan lead to violation of target quality metrics if estimated parametersare assumed to be the true ones. The sampling error for n samples may beavoided by increasing the multiplier αto α′=((1+n) (ε^((α^2)/n)−1))^(1/2) >α. For example, if n =60 and α=3, α′=3.14.

Burstiness at multiple time scales has been observed in Internet datatraffic. The variability of the window averaged bandwidth of suchtraffic over a given window may increase for smaller window sizes. Apredictor based on a given sampling window can underestimate thebandwidth required to satisfy the QOS of the SLA specified at shortertime scales. A prior knowledge of the scaling relations betweenbandwidth variance at different time scales can be used to correct themultiplier cc in order to accommodate short time scale variability.

FIG. 8 shows a flow chart for an exemplary process of an access point218-224 such as access point 218 for supporting a VPN. In step 2000, thehose interface 330 receives data packets from the hose 210 and goes tostep 2002. In step 2002, the controller 310 determines whether the hoseprofile has been exceeded. If exceeded, the process goes to step 2004;otherwise, the process goes to step 2006. In step 2004, the controller310 forwards the received data packet to the IP network interface 320 tobe transmitted to the destination via a best effort service, forexample. The best effort service may include dropping the data packetbecause network resources are not available for sending the data packetto its destination. Then, the process goes to step 2008. In step 2006,the controller 310 examines the data packet header to determine the QOSof the data packet and forwards the data packet to the next node 302based on a routing path that is initialized when the VPN wasestablished. Then the process goes to step 2008. In step 2008, thecontroller 310 determines whether more data packets have been receivedvia the hose interface 330. If more data packets have been received, theprocess returns to step 2000; otherwise, the process goes to step 2010.In step 2010, the controller 310 determines whether a system endcondition is detected. If detected, the process goes to step 2012 andends; otherwise, the process returns to step 2008.

FIG. 9 shows a flow chart for a monitoring process of the VPN serviceprovider. In step 3000, the VPN service provider determines whether thetime to determine whether resizing is necessary has been reached. Ifreached, the VPN service provider goes to step 3002; otherwise, the VPNservice provider returns to step 3000. In step 3002, the VPN serviceprovider collects measurement data from nodes 302 and/or access points218-224 and optionally executes the traffic predictor via the predictiondevice 350, for example. Then the VPN service provider goes to step3004. In step 3004, the VPN service provider compares the predictedtraffic to allocated thresholds.

Multiple thresholds may be used. For example, when the predictedcapacity exceeds an upper bound threshold, then additional capacityshould be allocated for the VPN and the VPN service provider goes tostep 3008. When the predicted capacity falls below a lower boundthreshold, then the allocated resources should be reduced and the VPNservice provider goes to step 3006. If the predicted capacity is betweenthe upper bound and the lower bound thresholds, then the currentresource allocation is acceptable and the VPN service provider goes tostep 3022.

In step 3006, the VPN service provider reduces resource allocation ofaccess points 218-224 and nodes 302 that are within the routing paths ofthe VPN and the VPN service provider goes to step 3011. In step 3011,the VPN service provider determines whether the hose profiles of the VPNshould be renegotiated. If renegotiation is required, the VPN serviceprovider goes to step 3013; otherwise, the VPN service provider goes tostep 3022.

In step 3008, the VPN service provider determines whether the predictedcapacity exceeds the hose profile thresholds. For example, thresholdsmay be set so that when the predicted capacity is within a predeterminedvalue specified in the hose profile, then an alarm condition is set todetermine whether the hose profile is required to be renegotiated. Ifthe hose profile thresholds have been exceeded, the VPN service providergoes to step 3012; otherwise the VPN service provider goes to step 3010.In step 3012, the VPN service provider renegotiates the hose profiles toincrease bandwidth and goes to step 3022.

In step 3010, the VPN service provider determines whether there isadditional bandwidth within the nodes 302 and/or access points 218-224of the routing path. If additional bandwidth is available, the VPNservice provider goes to step 3016; otherwise, the VPN service providergoes to step 3014. In step 3016, the VPN service provider increasesresource allocations based on the predictor capacities and goes to step3022.

In step 3014, the VPN service provider determines whether additionalbandwidth may be available in other nodes that may be a part of therouting path for the VPN. If available, the VPN service provider goes tostep 3020; otherwise, the VPN service provider goes to step 3018. Instep 3020, the VPN service provider changes the routing path of the VPNand allocates new resources so that the hose profile requirements may bemet and goes to step 3022. In step 3018, the VPN service provider setsflags to indicate that network resource upgrades may be required due toexcess demand for VPN services. Then the VPN service provider goes tostep 3022. In step 3022, the VPN service provider determines whether asystem end condition has been detected. If detected, the VPN serviceprovider goes to step 3024 and ends the process; otherwise, the VPNservice provider returns to step 3000.

The above described VPN service provider functions for establishing,managing and executing a VPN may be implemented by using a variety ofavailable protocols such as the Integrated Service (IntServ),differentiated services (DiffServ), or Multi-Protocol Label Switching(MPLS) as defined in the Internet Engineering Task Force. For example,in an IntServ framework, a signaling protocol may be used to allocateresources for hoses 210-216 between selected endpoints on an as-neededbasis. For this example, a customer network 202-208 may send signals viaa signaling protocol to an access point 218-224 to establish a hose210-216 and to identify endpoints of a VPN. The VPN service provider mayrespond by reserving resources within the IP network 250 by determiningrouting paths to the selected endpoints and setting up hoses 210-216 ateach of the endpoints. The RSVP protocol may be used to maintain theresource reservations across the nodes of the established routing path.If the VPN that is established is no longer needed, the signaling viathe RSVP protocol may be terminated resulting in releasing of theresources along the established routing path.

The DiffServ framework supports data packet marking so that various QOSlevels may be implemented. The MPLS environment uses labels to place inthe headers of data packets to determine routing paths that may becharacterized by a sink tree. A sink tree is routed at a hose egresspoint and the branches extend to ingress points of other hoses 210-216.Such a sink tree may also be considered a label switch path (LSP) tree.For example, the VPN service provider may use traffic measurements todetermine an actual spread of traffic from a hose egress point toseveral other hose ingress points and signal on each LSP involved toreserve the required resources. The signaling to create LSPs and toreserve reservations on such paths might be combined in a singleprotocol.

While this invention has been described with specific embodimentsthereof, it is evident that many alternatives, modifications, andvariations will be apparent to those skilled in the art. Accordingly,the preferred embodiments of the invention as set forth herein areintended to be illustrative, not limiting. Various changes may be madewithout departing from the spirit and scope of the invention.

1. A method for providing a virtual private network service, comprising:establishing a hose for each of a plurality of endpoints of a virtualprivate network, wherein the hose does not reference another endpoint ofthe virtual private network at establishment; coupling the hose toendpoints associated with other hoses via routing paths in a network;and allocating network resources to support communications between thehose and the other hoses, wherein the establishing comprises specifyinga service level agreement for the hose, the service level agreementincluding a hose profile and other information for controlling andmanaging the hose.
 2. The method of claim 1, wherein the establishingcomprises: first selecting one of a user managed hose type or a virtualprivate network service provider managed hose type for the hose; andsecond selecting whether to transmit marked data packets to the hose,results of the first and second selecting steps being stored in the hoseprofile.
 3. The method of claim 2, wherein if the user managed hose typeis selected, the method further comprising; specifying one or moreaggregate bandwidths for the hose; and specifying a time schedule foreach of the aggregate bandwidths, the aggregate bandwidths and the timeschedule being stored in the hose profile.
 4. The method of claim 3,wherein if data packet marking is selected, the method furthercomprising: receiving information regarding data packet markings and aquality of service corresponding to each of the data packet markings;and initializing the allocated network resources to provide the qualityof service based on the data packet markings if conditions in the hoseprofile is not violated.
 5. The method of claim 2, wherein if thevirtual service provider managed hose type is selected, the methodfurther comprising: receiving one or more quality of service levels forthe hose; establishing one or more sub-virtual private networks, eachsub-virtual network corresponding to one of the quality of servicelevels; specifying one or more bandwidths for the hose corresponding toeach of the sub-virtual private networks; and specifying one or moretime schedules for the bandwidths, the bandwidths and the time schedulesbeing stored in the hose profile.
 6. The method of claim 5, wherein ifdata packet marking is selected, the method further comprising:receiving information regarding data packet markings and a quality ofservice corresponding to each of the data packet markings; andinitializing the allocated network resources to provide the quality ofservice based on the data packet markings if conditions in the hoseprofile is not violated.
 7. The method of claim 1, further comprising:measuring communication traffic of allocated network resources togenerate monitoring data; generating a resizing condition based on themonitoring data; and resizing the allocated network resources if theresizing condition is within one or more thresholds of the hose profile.8. The method of claim 7, wherein the monitored data includes historicaldata, the method further comprising generating trend data to predictvirtual private network usage.
 9. The method of claim 7, wherein theresizing condition is one of above an upper bound threshold, below alower bound threshold, and within the upper bound and lower boundthresholds.
 10. The method of claim 9, further comprising: reducing theallocated network resources if the resizing condition is below the lowerbound threshold; and increasing the allocated network resources if theresizing condition is above the upper bound threshold.
 11. The method ofclaim 9, wherein if the resizing condition is below the lower boundthreshold by a predetermined amount, the method further comprisingrenegotiating the hose profile to change the service level agreement tobe more consistent with the monitored data.
 12. The method of claim 9,wherein if the resizing condition is above limits set by the hosethreshold, the method further comprising renegotiating the hose profileto change the service level agreement to be more consistent with themonitored data.
 13. The method of claim 7, wherein the resizingcondition determined based on a prediction of future virtual privatenetwork usage.
 14. A virtual private network in a network, comprising: aplurality of endpoints, each of the endpoints having a hose, wherein thehose does not reference another endpoint of the virtual private networkat establishment; and a plurality of routing paths in the network, therouting paths coupling the hose to endpoints associated with otherhoses; and a virtual private network service provider; the virtualprivate network service provider allocating network resources to supportcommunications between the hose and the other hoses, wherein the virtualprivate network service provider receives a service level agreement forthe hose, the service level agreement including a hose profile and otherinformation for controlling and managing the hose.
 15. The virtualprivate network of claim 14, wherein the virtual private network serviceprovider receives a first selection of one of a user managed hose typeor a virtual private network service provider managed hose type for thehose and a second selection of whether to transmit marked data packetsto the hose, results of the first and second selections being stored inthe hose profile.
 16. The virtual private network of claim 15, whereinif the user managed hose type is selected, the virtual private networkservice provider receives a specification forgone or more aggregatebandwidths for the hose, and a specification for a time schedule foreach of the aggregate bandwidths, the aggregate bandwidths and the timeschedule being stored in the hose profile.
 17. The virtual privatenetwork of claim 16, wherein if data packet marking is selected, thevirtual private network service provider receives information regardingdata packet markings and a quality of service corresponding to each ofthe data packet markings and initializes the allocated network resourcesto provide the quality of service based on the data packet markings ifconditions in the hose profile is not violated.
 18. The virtual privatenetwork of claim 15, wherein if the virtual service provider managedhose type is selected, the virtual private network service providerreceives one or more quality of service levels for the hose, establishesone or more sub-virtual private networks, each sub-virtual networkcorresponding to one of the quality of service levels, receives aspecification of one or more bandwidths for the hose corresponding toeach of the sub-virtual private networks, and receives a specificationof one or more time schedules for the bandwidths, the bandwidths and thetime schedules being stored in the hose profile.
 19. The virtual privatenetwork of claim 18, wherein if data packet marking is selected, thevirtual private network service provider receives information regardingdata packet markings and a quality of service corresponding to each ofthe data packet markings, and initializes the allocated networkresources to provide the quality of service based on the data packetmarkings if conditions in the hose profile is not violated.
 20. Thevirtual private network of claim 14, wherein the virtual private networkservice provider measures communication traffic of allocated networkresources to generate monitoring data, generates a resizing conditionbased on the monitoring data, and resizes the allocated networkresources if the resizing condition is within thresholds of the hoseprofile.
 21. The virtual private network of claim 20, wherein themonitored data includes historical data, the method further comprisinggenerating trend data to predict virtual private network usage.
 22. Thevirtual private network of claim 20, wherein the resizing condition isone of above an upper bound threshold, below a lower bound threshold,and within the upper bound and lower bound thresholds.
 23. The virtualprivate network of claim 22, wherein the virtual private network serviceprovider reduces the allocated network resources if the resizingcondition is below the lower bound threshold, and increases theallocated network resources if the resizing condition is above the upperbound threshold.
 24. The virtual private network of claim 22, wherein ifthe resizing condition is below the lower bound threshold by apredetermined amount, the method further comprising renegotiating thehose profile to change the service level agreement to be more consistentwith the monitored data.
 25. The virtual private network of claim 22,wherein if the resizing condition is above limits set by the hosethreshold, the method further comprising renegotiating the hose profileto change the service level agreement to be more consistent with themonitored data.
 26. The virtual private network of claim 20, wherein theresizing condition determined based on a prediction of future virtualprivate network usage.
 27. The virtual private network of claim 26,wherein the virtual private network service provider selects the routingpaths based on a shortest distance between pairs of endpoints of thevirtual private network to form a pipe between the pairs of theendpoints.
 28. The virtual private network of claim 26, wherein thevirtual private network service provider selects the routing paths basedon a source tree or a sink tree for each of the endpoints, and minimizesa bandwidth allocation between nodes of the network by maximizingsharing of same paths for branches of the source or the sink treeextending between different ones of the endpoints.
 29. The virtualprivate network of claim 26, wherein the virtual private network serviceprovider selects the routing paths based on source trees or sink treescorresponding to all endpoints of the virtual private network, andminimizes a bandwidth allocation between nodes of the network bymaximizing sharing of same paths for branches of the source or the sinktrees extending between different ones of the endpoints.
 30. The virtualprivate network of claim 26, wherein the virtual private network serviceprovider selects the routing paths based on source trees or sink treescorresponding to all endpoints of one or more virtual private networks,and minimizes a bandwidth allocation between nodes of the network bymaximizing sharing of same paths for branches of the source or the sinktrees extending between different ones of the endpoints for all thevirtual private networks.